System and method for dynamic imagery link synchronization  and simulating rendering and behavior of content across a multi-client platform

ABSTRACT

The present invention generally relates to systems and methods for simulation of web based content. Specifically, the systems and methods described herein are configured to provide simulation of the rendering and behavior of web (e.g., HTML) documents within multiple client, browser and device platforms. Although the principles can be generally used, the invention is particularly aimed towards simulating emails within different email clients and devices. Embodiments of the present invention further generally relate to synchronization of links with dynamic imagery provided to a remote computing device. Specifically, these embodiments of the invention relate to a web-based system and method for synchronizing URLs and other hyperlinks to dynamic imagery provided to a remote computing device by a server or other content providing device.

FIELD OF THE INVENTION

The present invention generally relates to systems and methods forsimulation of web based content. Specifically, the systems and methodsdescribed herein are configured to provide simulation of the renderingand behavior of web (e.g., HTML) documents within multiple client,browser and device platforms. Although the principles can be generallyused, the invention is particularly aimed towards simulating emailswithin different email clients and devices. Embodiments of the presentinvention further generally relate to synchronization of links withdynamic imagery provided to a remote computing device. Specifically,these embodiments of the invention relate to a web-based system andmethod for synchronizing URLs and other hyperlinks to dynamic imageryprovided to a remote computing device by a server or other contentproviding device.

CROSS REFERENCE TO RELATED APPLICATIONS

This present application claims the benefit of U.S. Provisional PatentApplication No. 61/913,419 filed Dec. 9, 2013, the entire disclosures ofwhich are incorporated herein by reference.

BACKGROUND

The need to test websites on different browsers and devices has alwaysbeen a bane of web developers. Web browsers often render documentsslightly different from each other and have varying support of HTML tagsand CSS styles. With the popularity of mobile devices, the problem hasbeen compounded as a web developer now has to test code on multipledevices in addition to the desktop.

The problem is even more acute in the space of email design. In theinterest of enhancing privacy and security many email clients disableimages, strip and modify certain HTML elements and disable JavaScript.Email designers hence often need to follow very strict and narrow designguidelines—being careful to only use the lowest common denominator ofHTML so that the design renders nicely in the majority of email clients.

The advent of responsive web design has pushed email designers to usemore aggressive designs for example using designs that render in aformat that is specially designed for mobile screens when viewed onmobile devices. Currently the method to test designs are to load thedesigns in all the different email clients or to use an automated“screen capture” service such as Litmus, that loads the designs in theclients using virtual machines and takes a screenshot of the email. Thescreen capture process is tedious and time consuming since the designerneeds to send an email to the various email clients and services andhaving a screenshot taken.

Therefore, there is a need in the art for a system and method that willallow the simulation of email content being rendered in differentclients so that the designer is able to quickly see how the emailrenders in multiple different email clients and devices. These and otherfeatures and advantages of the present invention will be explained andwill become obvious to one skilled in the art through the summary of theinvention that follows.

SUMMARY OF THE INVENTION

Accordingly, embodiments of the present invention are directed toproviding a system and method that will allow the simulation of emailcontent being rendered in different clients so that a designer is ableto quickly see how the email renders in multiple different email clientsand devices.

According to an embodiment of the present invention, a method forsimulating rendering and behavior of content across a multi-clientplatform, said method comprising the steps of: receiving hypertextmarkup language (HTML) content at a computing device; loading HTMLcontent in a target client and a web browser on said computing device;comparing, via said computing device, differences in rendering andstructure between HTML content loaded in said target client and said webbrowser; and storing modification parameters for the target client.

According to an embodiment of the present invention, the method furthercomprises the steps of: modifying said HTML content according to saidmodification parameters; entering a rendering mode; applying clientspecific environment in a simulated environment; generating simulatedmarkup output based on said simulated environment and said modificationparameters; and displaying said simulated markup output on a displayelement.

According to an embodiment of the present invention, the method furthercomprises the steps of: generating modified markup output based on saidmodification parameters; and displaying said modified markup output on adisplay element.

According to an embodiment of the present invention, the modified markupoutput comprises adding a client stylesheet to said HTML content suchthat the HTML content mimics characteristics of the web browser.

According to an embodiment of the present invention, the modified markupoutput comprises executing JavaScript to attach event listeners to theelements of the HTML content such that the HTML content mimicscharacteristics of the web browser.

According to an embodiment of the present invention, the modified markupoutput comprises modifying the behavior of the browser that is renderingthe content itself such that the HTML content mimics characteristics ofthe web browser.

According to an embodiment of the present invention, the step ofcomparing differences in rendering and structure between HTML contentloaded in said target client and said web browser, comprises the stepsof: parsing a Domain Object Model (DOM) Tree to determine elements thatmay have been removed or added; obtaining computed style of each DOMelement within the HTML content; comparing each of the DOM elements tothe computed style in an original document; and parsing external,internal and inline styles for changes to the computed styles comparedto the original document.

According to an embodiment of the present invention, the step ofcomparing differences in rendering and structure between HTML contentloaded in said target client and said web browser, comprises the stepsof: parsing a Domain Object Model (DOM) Tree to determine elements thatmay have been removed or added; obtaining computed style of each DOMelement within the HTML content; comparing each of the DOM elements tothe computed style in an original document; and parsing and comparingthe HTML content.

According to an embodiment of the present invention, the step ofcomparing differences in rendering and structure between HTML contentloaded in said target client and said web browser, comprises the stepsof: parsing a Domain Object Model (DOM) Tree to determine elements thatmay have been removed or added; obtaining computed style of each DOMelement within the HTML content; comparing each of the DOM elements tothe computed style in an original document; parsing external, internaland inline styles for changes to the computed styles compared to theoriginal document; and parsing and comparing the HTML content.

According to an embodiment of the present invention, a computerizedsystem for simulating rendering and behavior of content across amulti-client platform, said system comprising: an application modulecomprising computer-executable code stored in non-volatile memory; ameans for communicating data across one or more digital networks, and aprocessor, wherein said application module, said means for communicatingdata across one or more digital networks and said processor are operablyconnected and configured to collectively: receive hypertext markuplanguage (HTML) content; load HTML content in a target client and a webbrowser; compare differences in rendering and structure between HTMLcontent loaded in said target client and said web browser; and storemodification parameters for the target client.

According to an embodiment of the present invention, said means forcommunicating data across one or more digital networks and saidprocessor are further configured to collectively: modify said HTMLcontent according to said modification parameters; enter a renderingmode; apply client specific environment in a simulated environment;generate simulated markup output based on said simulated environment andsaid modification parameters; and display said simulated markup outputon a display element.

According to an embodiment of the present invention, said applicationmodule, said means for communicating data across one or more digitalnetworks and said processor are further configured to collectively:generate modified markup output based on said modification parameters;and display said modified markup output on a display element.

According to an embodiment of the present invention, said applicationmodule, said means for communicating data across one or more digitalnetworks and said processor are further configured to collectively:parse a Domain Object Model (DOM) Tree to determine elements that mayhave been removed or added; obtain computed style of each DOM elementwithin the HTML content; compare each of the DOM elements to thecomputed style in an original document; and parse external, internal andinline styles for changes to the computed styles compared to theoriginal document.

According to an embodiment of the present invention, said applicationmodule, said means for communicating data across one or more digitalnetworks and said processor are further configured to collectively:parse a Domain Object Model (DOM) Tree to determine elements that mayhave been removed or added; obtain computed style of each DOM elementwithin the HTML content; compare each of the DOM elements to thecomputed style in an original document; and parse and comparing the HTMLcontent.

According to an embodiment of the present invention, said applicationmodule, said means for communicating data across one or more digitalnetworks and said processor are further configured to collectively:parse a Domain Object Model (DOM) Tree to determine elements that mayhave been removed or added; obtain computed style of each DOM elementwithin the HTML content; compare each of the DOM elements to thecomputed style in an original document; parse external, internal andinline styles for changes to the computed styles compared to theoriginal document; and parse and comparing the HTML content.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a schematic overview of a computing device, inaccordance with an embodiment of the present invention;

FIG. 2 illustrates a network schematic of a system, in accordance withan embodiment of the present invention;

FIG. 3 is an illustration of an exemplary process flow, in accordancewith an embodiment of the present invention—depicting the process ofdetermining the modification parameters of a client environment;

FIG. 4 is an illustration of an exemplary process flow, in accordancewith an embodiment of the present invention—depicting the process ofsimulating the rendering and behavior of content within a clientenvironment; and

FIGS. 5A and 5B. are illustrations of an exemplary embodiment of a userinterface used to simulate the rendering and behavior of content withina client environment.

FIG. 6 is an overview diagram of an exemplary web based system forproviding the system and methods described herein, in accordance with anembodiment of the present invention;

FIG. 7 is an interaction diagram, in accordance with an embodiment ofthe present invention.

FIG. 8 is a timeline that details transitioning of an animated image andlink as embedded in an HTML document (e.g., HTML email), in accordancewith an embodiment of the present invention;

FIG. 9 is an illustration of an exemplary process flow, in accordancewith an embodiment of the present invention.

FIG. 10 is an illustration of an exemplary process flow, in accordancewith an embodiment of the present invention.

FIG. 11 is a diagram detailing 3 exemplary embodiments of an identifiercapable of tying a client to timer data, in accordance with anembodiment of the present invention.

DETAILED SPECIFICATION

The present invention generally relates to systems and methods forsimulation of web based content. Specifically, the systems and methodsdescribed herein are configured to provide simulation of the renderingand behavior of web (e.g., HTML) documents within multiple client,browser and device platforms. Although the principles can be generallyused, the invention is particularly aimed towards simulating emailswithin different email clients and devices.

According to an embodiment of the present invention, the system andmethod is accomplished through the use of one or more computing devices.As shown in FIG. 1, One of ordinary skill in the art would appreciatethat a computing device 100 appropriate for use with embodiments of thepresent application may generally be comprised of one or more of aCentral processing Unit (CPU) 101, Random Access Memory (RAM) 102, astorage medium (e.g., hard disk drive, solid state drive, flash memory,cloud storage) 103, an operating system (OS) 104, one or moreapplication software 105, one or more programming languages 106 and oneor more input/output devices/means 107. Examples of computing devicesusable with embodiments of the present invention include, but are notlimited to, personal computers, smartphones, laptops, mobile computingdevices, tablet PCs and servers. The term computing device may alsodescribe two or more computing devices communicatively linked in amanner as to distribute and share one or more resources, such asclustered computing devices and server banks/farms. One of ordinaryskill in the art would understand that any number of computing devicescould be used, and embodiments of the present invention are contemplatedfor use with any computing device.

In an exemplary embodiment according to the present invention, data maybe provided to the system, stored by the system and provided by thesystem to users of the system across local area networks (LANs) (e.g.,office networks, home networks) or wide area networks (WANs) (e.g., theInternet). In accordance with the previous embodiment, the system may becomprised of numerous servers communicatively connected across one ormore LANs and/or WANs. One of ordinary skill in the art would appreciatethat there are numerous manners in which the system could be configuredand embodiments of the present invention are contemplated for use withany configuration.

In general, the system and methods provided herein may be consumed by auser of a computing device whether connected to a network or not.According to an embodiment of the present invention, some of theapplications of the present invention may not be accessible when notconnected to a network, however a user may be able to compose dataoffline that will be consumed by the system when the user is laterconnected to a network.

Referring to FIG. 2, a schematic overview of a system in accordance withan embodiment of the present invention is shown. The system is comprisedof one or more application servers 203 for electronically storinginformation used by the system. Applications in the application server203 may retrieve and manipulate information in storage devices andexchange information through a Network 201 (e.g., the Internet, a LAN,WiFi, Bluetooth, etc.). Applications in server 203 may also be used tomanipulate information stored remotely and process and analyze datastored remotely across a Network 201 (e.g., the Internet, a LAN, WiFi,Bluetooth, etc.).

According to an exemplary embodiment, as shown in FIG. 2, exchange ofinformation through the Network 201 may occur through one or more highspeed connections. In some cases, high speed connections may beover-the-air (OTA), passed through networked systems, directly connectedto one or more Networks 201 or directed through one or more routers 202.Router(s) 202 are completely optional and other embodiments inaccordance with the present invention may or may not utilize one or morerouters 202. One of ordinary skill in the art would appreciate thatthere are numerous ways server 203 may connect to Network 201 for theexchange of information, and embodiments of the present invention arecontemplated for use with any method for connecting to networks for thepurpose of exchanging information. Further, while this applicationrefers to high speed connections, embodiments of the present inventionmay be utilized with connections of any speed.

Components of the system may connect to server 203 via Network 201 orother network in numerous ways. For instance, a component may connect tothe system i) through a computing device 212 directly connected to theNetwork 201, ii) through a computing device 205, 206 connected to theWAN 201 through a routing device 204, iii) through a computing device208, 209, 210 connected to a wireless access point 207 or iv) through acomputing device 211 via a wireless connection (e.g., CDMA, GMS, 3G, 4G)to the Network 201. One of ordinary skill in the art would appreciatethat there are numerous ways that a component may connect to server 203via Network 201, and embodiments of the present invention arecontemplated for use with any method for connecting to server 203 viaNetwork 201. Furthermore, server 203 could be comprised of a personalcomputing device, such as a smartphone, acting as a host for othercomputing devices to connect to.

The present invention generally relates to the ability to simulate therendering of an HTML document in multiple environments. Embodiments ofthe present invention are particularly beneficial to the testing ofemail design and the majority of the disclosure will focus on email.However, embodiments of the present invention can be applicable to otherinstances where HTML is used and not just for email.

As used herein, the term web browser relates to any application that isable to consume and parse HTML content and may be a fully-fledgedweb-browser, such as Firefox® or Chrome®, a component within anapplication such as the HTML rendering component in Microsoft® Outlook®or the iOS® Mail application, or a component without a user-interfacesuch as a headless WebKit engine. The term Client relates to any emailclient, however client can be interpreted in a broader manner to addressother container of HTML content.

Part 1: Programmatic Detection of Characteristic of Client Environment.

An email may render differently in many different clients especially inWebmail environments such as GMAIL®, YAHOO! ® Mail and HOTMAIL®. Theseclients frequently modify the HTML elements within an email messagewhich may include: (i) stripping certain functionality and tags (ie.style and script tags); (ii) removing certain styles (ie. styles thathave position set to “absolute”); (iii) modifying certain styles; (iv)adding extra styles (so that the email looks more native to the emailclient); or (v) any combination thereof. These modifications arereferred to as client modification parameters.

A preferred method to detect the modifications performed by the clientsinvolves creating an HTML content containing permutations of HTML tagswith CSS styles and tracking the changes made to the markup and behaviorof the content when loaded in a web browser and having it loaded in aclient. Turning to FIG. 3, at step 301, the document is selected andloaded into a regular web browser 303 as well as a selected client 302.The process of loading the content in a client may differ depending onthe type of client. For some clients such as web-based email clientssuch as HOTMAIL® and GMAIL®, the process may involve sending the contentas an email to an address hosted by the web-based email client's serversand logging into the website hosting the web-based email client and thenopening the sent message. A preferred embodiment of the inventionautomates the process of loading content within clients and web browsersby interfacing with applications that are able to programmaticallycontrol the execution of web-browsers, such as Selenium Web Driver orother mechanisms familiar to those skilled in the art.

When the HTML content is loaded in the client and web-browser, theoriginal content 303 is then compared to the content rendered in theclient 302. According to a preferred embodiment of the presentinvention, to perform the comparison the system may be configured to usea plugin that attaches to a web-browser or client. The plugin is able toinspect the content rendered within the client. Such plugins arefamiliar to those skilled in the art. Another method to perform thecomparison is to use a scriptable web-browser such as the headlessWebkit engine wherein the content loaded by the engine can be accessedby an external application to perform the comparison.

When the email content is rendered, the Document Object Model (DOM) ofthe content is accessed and one or more of the forgoing processes areperformed by the system to determine the modification parameters thathave been applied to the original HTML content) 304: (i) parsing of theDOM Tree to determine elements that may have been removed or added; (ii)obtaining computed style (such as font, width, height) of each DOMelement within the email and comparing the DOM elements to the computedstyle in the original document; (iii) parsing the external, internal andinline styles for changes to the styles compared to the originaldocument; (iv) parsing and comparing the HTML document, or (v) anycombination thereof.

With respect to (ii) above, the computed style is not limited to thestyle that has been set directly on the element but includes all othersettings that may have cascaded from parent elements and othermodifications. For instance, specifically checking the computed style'swidth and height of an element allows the application to quicklydetermine if there is a discrepancy in the layout of bothdocuments—which may be caused by among others, differences in fontsizes, padding or the removal of certain styles and elements. Obtainingthe differences in computed styles allows an application to determinethe transformation that has been applied to the email. If certaintransformation cannot be determined—for example in the case of unknownchanges in dimensions, the offending elements can be identified by theapplication and marked for manual inspection. The dimension checks allowfor a more efficient troubleshooting by a user since it narrows the areaof inspection and it identifies minute changes in dimensions that maynot be obvious to the naked eye. For certain email documents that aredesigned to be responsive or change based on the width or size of thecontainer holding the email, the computed style process can be repeatedfor various container sizes to identify if discrepancies arise in otherdimensions and container size.

With respect to (ii) above, by comparing the styles in the email clientthat are being applied to the content, would result in thetransformation that have been applied style wise to the document.

With respect to (iv) above, comparing the HTML of the transformeddocument and the original document would yield HTML structure changesthat may not be detected by the DOM computed style and style sheetparsing routines, but may yield less valuable and actionable data.

In addition to the automated detection of differences, certainmodification procedures may require the manual edit of a user to verifyand adjust these parameters.

The modification parameters are then recorded and stored 306 with anidentifier of the client being tested on so that the parameters can beretrieved later to be applied to content to simulate the clientenvironment. At this point, the process terminates at step 307.

Often clients may change and client modification parameters may becomeoutdated. According to preferred embodiments of the present invention,the system is configured to run a configuration application periodicallythat will run the above mentioned process on a list of clientenvironments and compare the results to the results obtained prior. Ifthere is a change in the result that matches certain criteria, a clientenvironment can be marked for retest and a notification be sent to anadministrator that such change has occurred.

Part 2: Transforming Web Document to Simulate Rendering and Behavior inClient Environment

The discussion herein focuses on using the client modificationparameters derived from the process of Part 1, and applying them to aweb document to simulate the rendering and behavior in targeted clientenvironments.

Turning now to FIGS. 5A and 5B. is an illustration of an exemplaryembodiment of a user interface used to simulate the rendering andbehavior of content within a client environment. The user interface 500allows a user to input HTML content 501 (including but not limited toCSS and Javascript). The user interface may contain options that allowsthe user to view the content in multiple ways, including: (i) displayingthe HTML content as markup or rendered 502; (ii) displaying the modifiedHTML content simulated within a selected target client 504 environmentas markup or rendered 503; (iii) blocking or displaying images withinthe rendered view 507; or (iv) any combination thereof.

When the user finishes selecting the options, the user interface maythen render the modified HTML content within a view. Element 505 showsthe modified content as markup and element 306 shows rendered modifiedHTML content.

The forgoing delves into the process to transform HTML content by auser. Turning to FIG. 4, initially the user will load the clientsimulation tool 401 and enters the HTML content 402. In certainembodiments, the system can be a web-based application hosted on aserver and accessed from a web-browser. The user can then selectmultiple options to render the content within a target clientenvironment 403. In certain embodiments of the present invention, one ofthe options is the selected client environment.

At step 404, the content is processed by the system wherein the systemretrieves the client modification parameters that specify how thecontent is to be modified to simulate the selected client environment.The HTML markup is altered to simulate how a target client environmentwould alter the HTML markup. Altering a markup may involve adding,removing and modification of styles as well as adding and removing ofHTML elements.

If the user selected to render the simulated output in markup (step 405)then the modified markup is displayed 406 to the user in a window orother graphical user interface (GUI). If the user selected to render thesimulated content (step 407), the simulated environment is applied basedon the client modification parameters. This part is done when themodified HTML content is being rendered of after it has been rendered.Environment modification may include adding a client stylesheet,executing JavaScript to attach event listeners to the elements of theHTML content as well as modifying the behavior of the browser that isrendering the content itself such that it mimics the characteristic ofthe type of browser that the selected client is run on—this isespecially advantageous when the selected client is a desktop clientsuch as Microsoft Outlook or mobile client.

In the case wherein the target environment is a mobile client, certainadditional modifications may be advantageous. Unlike desktop and webclients, certain user interactions are either not available or arehandled differently by the client. For example since the majority ofmobile clients do not employ a cursor, there is no concept of a “hover”whereby a user places the cursor over an element. In web or desktopenvironments designers can create HTML content that responds to a hoverevent by using the “:hover” pseudo-class on an element. By using the:hover pseudo-class for example, elements can alter their styleproperties when users hover the cursor over an element such as color,width, height and padding, adding an element of interactivity to thedocument. One of ordinary skill in the art would appreciate that thereare numerous types of interactions that are implicated by mobileclients, and embodiments of the present invention are contemplated foruse with and for the processing of any such interaction.

On mobile environments that do not use cursors, some clients such as theiOS (iPhone) and Android clients trigger the hover event when the userperforms a quick tap of the element that has been associated with ahover pseudo-class. When simulating a mobile client on a desktop webbrowser, it would be advantageous to treat the cursor as a user's fingerand only trigger the hover event when the user has actually clicked (ie.tapped) on an element—instead of triggering a hover event when thecursor is merely over the element. In the preferred embodiment, thesimulation user interface uses a desktop web browser which will bydefault trigger the hover event when a cursor is placed over anelement—and modifying the environment to simulate a mobile hoverexperience instead. The simulation may also be run on a mobile browser,wherein the interaction modifications would be reversed—whereinweb/desktop client environments and interactions are simulated in amobile browser.

The following discusses the process of modifying the hover interactionhandling of a desktop web browser (or any browser that responds to ahover event using a pointing device such as a mouse) so that a hoverevent is only triggered when a user clicks on an element and not whenthe user places the cursor over an element. The original HTML documentmay assign the :hover pseudo-class to elements that are set to respondto hover events. In order for the browser to not trigger a hover eventon a cursor hover, in an exemplary embodiment, the application converts“:hover” pseudo-classes to regular classes at the markup modificationphase (FIG. 4 step 404). For example, :hover can be changed to a regularnamed class such as myhover so that declarations such as .mydiv:hoverbecomes.mydiv.myhover. Then during the environment modification phase407, a script is run where click event listeners are bound to elementsoriginally having :hover pseudo-classes. When the click event listeneris fired, the myhover class is added to the element, thus making activethe styles that have originally been assigned the :hover pseudo-class.However, there is also a need to undo the application of the myhoverclass once the user has clicked on another element. This can be done bykeeping a list of elements that the myhover class has been applied toand removing the classes from those elements before applying the classto elements that have the abovementioned click listener that have beenrecently clicked on. In a preferred embodiment of the invention, theelements receiving a click event are queued into a list and elementspreviously having being added the hover class have the hover classremoved, before the hover class is added to the newly clicked onelements.

Some mobile environments also only trigger hover events when certainspecific type of elements are touched (ie. images or links), so to mimicthat behavior, click events may be selectively applied to those types ofelements within the elements having hover pseudo-classes. This can bedone using query selectors—so if the original style was .myclass:hover,and only links may trigger hover events, the querySelector used totarget links within the element may look like “.myclass a” wherein clickevents are then added only to the links and not the initial elementitself.

One skilled in the art can appreciate that other CSS classes andpseudo-classes may be simulated in the manner above. It would also beadvantageous to simulate media queries as well. Media queries are CSSblocks that become active when certain conditions are met, such as“max-width”, wherein the block within the query is active only if thecurrent browser or client width is smaller than the max-width variable.

@media max-width: 330 px { . . . }

There are some media queries target the device such as“max-device-width”. In order for the media query targeted to devicedimensions to be active within a simulated environment a few methods maybe employed. Firstly during the markup modification phase, the systemcan detect device or environment specific CSS media queries and makethem active by default if the system determines that the CSS block wouldbe active (or enabled) in the target client environment. This is ineffect removing the media query filter itself and having the block ofCSS within the media query be automatically active. An alternateapproach would be to modify the browser running the simulation torespond to media queries differently depending on the simulated clientenvironment. It is more advantageous to take the former route as it doesnot require the modification of the browser.

Other methods to simulate client environments may be used in conjunctionwith the methods described above. Some other simulation of mobileenvironments include simulating the effect of (i) meta tags specific tomobile environments such as “viewport”, wherein JavaScript is used tosimulate mobile behavior when the viewport meta tag is present—forexample when width restrictions are set in the viewport meta tag, theapplication can create boundaries for the content container to match thewidth restrictions (ii) styles specific to mobile client environmentssuch as the iOS Mail app setting a minimum font size and modifying fontswithin the HTML content to comply with said restrictions or detectingstyles settings such as “-webkit-text-size-adjust:none” wherein the fontsize restriction is overridden.

A preferred embodiment of the invention also includes the ability toprogrammatically determine discrepancies in the rendering between theoriginal HTML content and the HTML content within a list of clientenvironment. This allows the system to notify the user to identifypotential rendering and layout issues without the user having tomanually view the rendering of the HTML content in multiple clientenvironments. The discrepancy detection can be done by having theoriginal HTML content being modified to simulate a plurality of clientenvironments, and then performing one or more of the below processesusing the client environments: (i) parsing the DOM Tree to determineelements that may have been removed or added; (ii) obtaining thecomputed style of one or more DOM element within the client environmentcompared to the computed style in the original document; (iii) parsingthe styles to detect the application, or removal of styles andpseudo-classes such as :hover to detect if there will be changes ofbehavior between the original HTML document and the selected clientenvironment; or (iv) any combination thereof. With respect to (iii)above, specifically checking the computed style's width and height of anelement allows the system to quickly determine if there is a discrepancyin the layout of both documents. It further allows the system to checkother discrepancies as well as other attributes including but notlimited to as font, color, border, padding, margin, spacing andline-height. The computed style may be computed using JavaScript such asusing document.defaultView.getComputedStyle(element) orelement.currentStyle for Internet Explorer. One of ordinary skill in theart would appreciate that there are numerous methods that could beutilized to make such determinations, and embodiments of the presentinvention are contemplated for use with any such method. The applicationcan then highlight the discrepancies on the various client environmentsthe user using the simulation tool so that the user can perform asimulation on said environments to delve into the discrepancies.

Part 3: Detection of Outlier Clients

As email clients and web browsers get more and more sophisticated, thecapability gap between new clients and old clients get larger and incertain cases use of new features within HTML content such as HTML5 andCSS3 cause rendering problems on old clients. A common method to addressthis is to only use a narrow set of features in HTML content to supportthese clients. However as the old clients become fewer and fewer, thevalue in supporting the old clients diminishes. Yet it would beadvantageous to allow users using the old clients to signal that theywould like content that render properly in their clients as well as away for email senders to send content that render properly for theseclients.

A method to allow users of old clients to signal to the sender that theuser is using an old client is that the sender may place text or linkswithin an email message that is only visible when viewing the content onan old or “unsupported” client. Such techniques involve putting links tothe “text only” (“text/plain” multipart mime) part of an email, or toportions of an HTML email that is specifically crafted such that thelinks or text would be hidden in modern clients or browsers. For examplemodern clients allow HTML elements to be effectively hidden by allowingone of the following style tags display:none; or overflow:hidden withheight or width set to 0 px. By putting text or links within thoseelements styled that way, only old clients that don't support thosestyles will display them.

These links, when clicked on or placed in a browser, could take the userto a service hosted on a server that record that the user is on an oldor unsupported client and that future emails should take that intoaccount. The links may have identifiers identifying the user or user'semail address embedded or encoded into them so that the hosted servicecan easily determine the email address of the user. When the servicereceives the request, the user's record is updated to reflect that theuser is on an old or unsupported client.

Later during the process of sending an email to said recipients, theapplication that is processing the email to be sent can modify the emailso that it renders correctly on their clients. The creator of the HTMLcontent being sent may provide hints to the application within the HTMLcontent signifying portions of the content that should be modifiedincluding the replacement portions for old clients that do not supportmore advanced functionality—such as using conditional comments orapplication specific directives.

An alternate and more conservative method to deal with outlier clientsis to embed links to tiny images on a server or “pixels” that will onlybe loaded by newer and more advanced clients. This can be done byplacing the images using the more advanced CSS styles such asbackground:url(<image link>) which will be ignored by old clients. Thelinks to images embed identifiers identifying the user or user's emailaddress and when loaded from a server, the server is able to identifythat the user is on a modern client and to update this information inthe user's record. Later when email is sent, a process sending the emailwill modify the HTML content such that users not having a record thatthey are on a modern client will be sent emails that only render on oldclients.

Part 4: Reporting of Triggering of Interactive Elements in Clients

Certain clients support specific elements, such as the CSS :hoverpseudo-class. As mentioned previously the :hover pseudo-class supportallows for interactivity within the HTML content. It is desirable todetect when interactive elements are triggered by users remotelyespecially in the case of email where the ability to detect thetriggering of an interactive element allows the sender to determine bothusers using a client that supported interactive element as well aswhether the addition of interactive elements affected the results of anemail campaign.

A preferred method to detect if an interactive element has beentriggered by a user in a client is to place tiny images called pixelsthat are only displayed when an interactive element is triggered—whereinthe image is loaded from a remote server and the URL of the imagecontains one or more identifiers that identifies one or both of—the user(or email) and the interactive element being triggered such that theremote server is able to record the triggering event and connect theevent to the user and/or the interactive element. Such a method may usefor example by placing a <div> element within an element that is set torespond to a :hover event, wherein the background-image of that divelement is set to a remote image once the hover event is triggered. Anexemplary CSS may look like this:

 .the_element:hover div {  background-image:url(http://removeserver.com/pixel?user=user@user.com&element=the_element);  }

Other methods to load pixels when an interactive element is triggeredmay be used. Other information may be encoded in the pixel as well whichmay include the email campaign identifier.

Part 5: Dynamic Imagery Link Synchronization

According to an embodiment of the present invention, the system andmethods described herein use synchronization techniques on one or moreservers in conjunction with a client (e.g., web browser such asMicrosoft Internet Explorer or Google Chrome—or native email client suchas Microsoft Outlook or iPhone Mail app) or other softwareidentification techniques to overcome current limitations and providethe ability to send a user to a URL or other hyperlink/contentidentifier (e.g., IP address) associated with one or more frames of animage being displayed to the user when the user clicks on the image. Oneskilled in the art can appreciate that the implementation does notnecessary tie a specific URL to a specific frame, other methods canachieve a similar outcome, such as tying URLs to specific times withinan animation timeline instead.

Although the techniques described herein apply to any animated imageincluding animated gif, animated png and video, the descriptions hereinwill primarily focus on the implementation using animated gifs. One ofordinary skill in the art would appreciate that there are numerous formsof content that embodiments of the present invention could be used inconjunction with, and embodiments of the present invention arecontemplated for use with any type of content.

While preferred embodiments of the present invention are contemplatedfor use with email content, other embodiments of the present inventioncan be equally beneficial in environments where the ability to embed orexecute scripts on the web page (e.g., by a client) such as javascriptis blocked or limited. One of ordinary skill in the art would appreciatethat there are numerous environments that embodiments of the presentinvention could be utilized with, and embodiments of the presentinvention are contemplated for use with any type of environment.

Further, although preferred embodiments of the present invention areconfigured to process dynamic image synchronization through use of ananimated image file, other embodiments of the present invention can beused to achieve the same effect while utilizing other content types,such as animated images generated on the fly from individual staticimages, or storing an animated image as several pieces such as storingthe header and first frame as a file and the remainder frames as aseparate file. One of ordinary skill in the art would appreciate thatthere are numerous types of content that could be utilized withembodiments of the present invention, and embodiments of the presentinvention are contemplated for use with any type of content.

Turning now to FIG. 6, an overview diagram of an exemplary web basedsystem for providing the system and methods described herein is shown.The diagram shows various entry points into the system by various typesof clients (e.g., browsers 100, native email clients 110). Components ofthe system may include, but are not limited to, an origin web page serer101, an image server 103, a link handling server 105 and a destinationweb server 108. While these components are shown in FIG. 6 as separateservers, one of ordinary skill in the art would appreciate that thesecomponents could be provided by a single physical server or any numberof physical or virtual servers, whether residing on the same hardware orseparate hardware and communicatively connected through one or morecommunications means (e.g., wireless connections, wired connections,software connections). Further, one or ordinary skill in the art wouldappreciate that embodiments of the present invention may be accomplishedthrough the use of fewer or additional components than outlined in FIG.6.

In FIG. 6, browser 100 interacts first with a webmail sever 101 forreceipt of email from the webmail server 101. Native email client 110 isprovided its email directly from an email server (not shown) in anynumber of ways such as using the POP, IMAP, Exchange or proprietaryemail protocols, as would be appreciated by one of ordinary skill in theart. Upon opening an email, both browser 100 and native email client 110receive image data from image server 103. For the purposes of thepresent description, the image server 103 may provide an animated image104 to the browser 100 or native email client 110. In preferredembodiments of the present invention, in conjunction with distributingthe animated image 104, the image server 103 also places the clienttiming data (e.g., timer) 106 in a location that is accessable to linkhandling server 105—one embodiment of which is to place it on a cacheserver that is accessible by both the image server and link handler suchas a server that runs memcached, or to save the timing data in adatabase that is commonly accessible such as a database running MySQL.Armed with the timing data 106, the link handling server can use one ormore means to determine what frame is being displayed when browser 100or native email client 110 send a link request to the link handlingserver 105. The link handling sever 105 will process the link request inconjunction with the timing data 106 to select the appropriate URL fromthe list of URLs 107 and forward the client to the appropriatedestination web server 108 for the content 109 desired by the user ofthe client.

It should be noted that, in preferred embodiments of the presentinvention, the browser/client timing data 106 is an integral part toidentifying the appropriate link and content associated with the linkthat is desired by the user. In its simplest form, by noting thetransmission time and/or estimating a receipt and/or display time of theanimated image 104 to the browser 100 or native email client 110, thelink handling server 105 is capable of identifying what frame ofanimated image 104 is being viewed by the user at the time the userinteracts (e.g., clicks) the animated image 104 and therefore knows whatcontent 109 to send to the client, based on the frame being displayed tothe user.

The determination of the timing data may be based, at least in part, onother information known to the system. For instance, the system may beprovided various forms of metadata that could be utilized to determine abest time to start the timer. Metadata that could be used for thispurpose include, but are not limited to, browser type, browser version,email client type, email client version, packet size, connection type,connection speed, latency, service provider, client operating system, orany combination thereof. One of ordinary skill in the art wouldappreciate that there are numerous types of metadata that could beutilized with embodiments of the present invention, and embodiments ofthe present invention are contemplated for use with any type ofmetadata.

One important aspect to control for is the variance in transmissionrates and network quality between the components of the system and thecomputing device of the user, an important part of which includesdetermination of network speeds. When determining network speeds todetermine if the rate of delivery of an animated image is too slow, onemethod is to send a portion of data back to the client and record howmuch time has elapsed for a set amount of data to be delivered. Ideallythis calculation is done during the delivery of the first frame somitigation techniques can be employed such as aborting the delivery ofthe rest of the frames.

However, in most modern operating systems, the TCP socket buffer limitis normally defaulted to a value of 64K or higher (some much higher) andas a result if the frame or image size is smaller than 64K, the entireframe or image may be consumed by the buffer giving the impression tothe application that the data has been sent when it has not. There aretwo methods to deal with this: 1) To set the TCP socket buffer's maximumsize to a much smaller value so that the frames will not fit within thebuffer size (such as 20K) and thus the buffer will only consume the restof the frame data once sufficient data has been transmitted to theclient allowing the application to compute a more accurate throughputspeed of the connection; or 2) Increase the payload of the image beforethe next non-transparent frame. This can be done either by insertingframes between the first frame and the next non-transparent frame suchthat the size of the frame makes the payload prior to the nextnon-transparent frame larger than the TCP buffer or to alter non-imageportions of the payload (such as text and application extensions andcomments) to fill it with random non-consequential but valid data.

Since embodiments of the present invention utilize server sideprocessing to provide the synchronization functionality describedherein, embodiments of the system work equally well with cases where a)a web browser (e.g., Mozilla Firefox) is loading a web page containingone or more animated images with an associated link from a web server(e.g., webmail), and b) a native email client (e.g., Microsoft Outlook)that loads HTML content from its internal data store. One advantage ofutilizing server side processing is that no code or script is requiredto be executed by the client, making embodiments of the presentinvention platform independent and agnostic. There is no requirementthat a client be utilizing any particular software, browser, operatingsystem or other component other than the ability to process and displayanimated images such as an imaged gifs. This allows the system to beutilized on any platform, including mobile devices and other deviceswith limited processing power.

FIG. 7 is an interaction diagram, in accordance with an embodiment ofthe present invention. FIG. 7. details an exemplary flow of what happenswhen a request is made by the client to retrieve an animated image, in apreferred embodiment of the present invention. In an exemplaryembodiment, “timing data” (timer) may be formatted in the followingmanner:

Timing Data format:  { “image_id”: “img1000”,  “client_id”:“client1@client.com”,  “start_time”: 1359759420  “loop”:2, “total_anim_time”: “13.2”,  “urls”:[   {“time”:”0”, “url”:“http://url1.com”},   {“time”:”4.4”, “url”: “http://url2.com”},  {“time”:”8.8”, “url”: “http://url3.com”}  ]}

In the above pseudo-code format, the image_id is an identifier of theimage that is sent to the client (this identifier may not necessarily bean image identifier, but could be some other identifier such as acampaign identifier that has a relation to the image sent), theclient_id could be comprised of identification information, including,but not limited to, one or more of a cookie id, an IP address, an email,hashed value of the aforementioned values, or any combination thereof.The start time could be configured in any appropriate format (e.g.,epoch (seconds since midnight Jan. 1, 1970) GMT, a string designating aspecific date and time at a specific timezone). Loop defines the numberof times the animation will loop once it reaches the end of the sequenceof images and the total_anim_time defines the total duration of theanimation/video. URLS indicates the various links that may be provided,depending on when the image is interacted with by the user (e.g., 0-4seconds url1, 4.4-8.8 seconds url2 and 8.8-13.2 seconds url3. One ofordinary skill in the art would appreciate that this is merely anexample and there are numerous ways to format and provide the encodingfor such timer data, and embodiments of the present invention arecontemplated for use with any type of timing data.

Turning now to FIG. 8, a timeline that details transitioning of ananimated image and link as embedded in an HTML document (e.g., HTMLemail), in accordance with an embodiment of the present invention, isshown. The top portion of FIG. 8 shows pseudo-code for the inclusion ofan animated image in an email (HTML format). In an exemplary embodiment,the image url and the link that wraps the image may be formatted in thefollowing manner:

image url:http://image-server.com/get_image?image_id=img1000&user=bill@yahoo.comlink:http://link-handler.com/redirect?image_id=img1000&user=bill@yahoo.com

In the above example, image_id identifies the image to be sent back tothe client and the “user” parameter can be used as a client identifier.Although the image url and link refer to different servers, there is norequirement that it is so and both the image and link can be served andhandled by the same server. Also as discussed elsewhere in thisdocument, the user parameter is not mandatory as there can be multiplemethods to determine a suitable client identifier (client id). In theabove example, the image id and client id together serve as a key thatthe timing data (timer) linked with. However other methods to generate akey for the timer can be used such as using only the client_id or thelink instead of having both an image_id and a client_id the linkcontains a single id that allows the image server to uniquely identifyboth the image and client. Also an alternative to a regular link, thelink could also be an image map link, where different coordinates of theimage is associated with a different link. The image map can be eitherclient side where the coordinates are mapped to links within the page orserver side where the coordinates of the activated (clicked or touched)event within the image is sent to the server and the server uses thecoordinates to determine which area the image has been activated(clicked/touched) and to send the user to an appropriate link. Using animagemap allows multiple links to be associated with a frame of theanimation. The exemplary disclosure references a regular link althoughone skilled in the art can appreciate the opportunities to use imagemaps with said invention.

The bottom portion of FIG. 8 shows the progression of an animated imagethrough various frames/phases. In this embodiment, the animated imagemay have one or more transitional frames allowing for the transitionbetween a first and second image (primary frames) of the image set ofthe animated image. Transitional frames may be identified by either theshort amount of delay the frame is viewable before being replaced (eg.less than 1 second) or that the frame can be marked as a transitionalframe by adding data to the metadata of the frame, for example bysetting an application specific flag within a gif frame's applicationextension block The system described herein can handle thesetransitional frames in a number of manners, including, providing eachframe with their own link, grouping together a non-transitional framewith the next sequential transitional frames with one link, providingone or more of the transitional frames with their own link, providingonly the non-transitional frames with their own links, providing some ofthe transitional frames links but not others, providing some of thenon-transitional frames with their own links and not others, and anycombination thereof.

FIG. 9 is an illustration of an exemplary process flow, in accordancewith an embodiment of the present invention. The process of FIG. 9follows the actions of an image server acting in conjunction with anembodiment of the present invention. At the first step, the image serverreceives a request from a client to receive an image requested from codeembedded in an email (e.g., HTML). The image server then determines theidentifier of the image being requested (image_id), an identifier forthe client requesting the image (client id) and the capabilities of theclient to display and handle animated images and other capabilities(optional). In an exemplary embodiment, the capability check is beingdone by reading the “User Agent” string being passed along with therequest by the client. The User Agent string may inform the applicationthe type of client that is accessing the server (such as MozillaFirefox, Microsoft Outlook). Based on the knowledge of the client, theimage server may make a determination that the client is not suitable(e.g., certain versions of Microsoft Outlook will not display theanimation within an animated image). The client identifier may be basedat least in part on one or more of a cookie, a specific parameter withinthe image url that is used as a client id, an IP address, a hostname,metadata associated with the embedded code, or any combination thereof.One of ordinary skill in the art would appreciate that there arenumerous methods for determining the identity of a client requesting animage from an image server.

If no client_id is available, or if the application deems that theclient is not capable to either render the animated image or pass anyother predefined criteria, the image server can be configured to providea default image to the client. This image would have a single URLassociated with it so that no matter what frame the user clicked on, theendpoint would be the same content located at the specified URL. In thisspecific embodiment, no timing data is created since the timing is notrelevant. However in other embodiments timing data can be created butmarked that an image with a single url has been sent to the client. Atthis point the process would end.

If a client_id was ascertained, the image server may create a timer andassociate that timer with both the image id and client_id using thecombination as a key. This timer and associated information may bestored in a database, in memory, on a separate machine or other datastore for later retrieval by the link handler. An expiry may be placedwith the timing data to ensure that old timer data is eventuallydiscarded or deemed invalid. The timer may contain multiple pieces ofdata that the link handler can use to determine which URL to send theclient to an exemplary example disclosed earlier in this document. Amongthe data, for instance, may include a timestamp for the time at whichthe image is deemed to have begun displaying at the client. Thistimestamp may be approximate. In alternate embodiments, the timestampmay be the time the transmission began, the time the transmission beganwith a delay to take into account network delays determined by theconnection speed, the time the transmission began with a delaydetermined by the specific characteristics of the client, upon a givendelay, or any combination thereof. One of ordinary skill in the artwould appreciate there are numerous methods for determining the besttime to initiate the timer, and embodiments of the present invention arecontemplated for use with any of these methods.

In conjunction with determining the optimal timer start time, the timerstart time may be set or the timer itself being created during theprocess of streaming the image to the client. Also the User Agent stringmay be used to determine the characteristic of the image being deliveredto the client. For example for mobile clients a version with lessframes, different frame timing/loop settings, a smaller dimension/sizeoptimized for small screens or a combination but not limited to theaforementioned may be sent to the client.

While the image is being streamed to the client, the image server mayalso be configured to determine if there is some error or other slowdownin the transmission or receipt of the image to the client. Errors andslowdowns include, but are not limited to, network issues, droppedpackets, security issues, connection issues, bandwidth issues, or anycombination thereof. One of ordinary skill in the art would appreciatethat there are numerous impendences that may slow down or cause errorsin the transmission and receipt of data between two points, any of whichmay be identified and processed by the present system. Assuming thereare no slowdowns, the image finishes streaming and the processterminates.

If there are issues, the system may be configured to mitigate for theslowdown based on the specific error/slowdown type and correctiveoptions available to the system. Options for dealing withslowdowns/errors include, but are not limited to, truncating an image ata frame boundary, dropping or altering transitional frames, alteringframe timings, inserting bank or transparent frames into the image, orany combination thereof. If the slowdown is especially severe and if theslowdown is detected while the first (visible) frame is being streamedone exemplary corrective option is to finish streaming the first frameand terminating the streaming (discarding the remaining frames) givingthe impression to the user that the image is a static image. Apreferable point to create the timer object is once the first frame hasbeen sent as this is a point where it is determined that the client willbe able to process more than one frame in the image. One of ordinaryskill in the art would appreciate that there are numerous types ofcorrective options that could be utilized with embodiments of thepresent invention, and embodiments of the present invention arecontemplated for use with any type of corrective option. If a correctiveoption is applied, the system can be configured to correct/update thetimer data to reflect the mitigation actions that have been taken whichmay include changes to timing or the elimination or addition of framesand finish streaming or otherwise complete the process and terminate. Anadditional measure that can be taken is to determine the type of clientusing the User Agent string retrieved and to look up in a pre-configureddatabase client specific behaviors in relation to the processing ofanimated images during a delay or slowdown in network transmission. Forexample certain browsers may truncate the display of the frames in orderto “catch up” to what it deems the proper timing of the animation,whereas others may respect the defined delay set within each frame anddisplay them with the pre-set delay as the frames get delivered to theclient. The application can match the client type to the behaviorinformation and adjust the timing data to match what it calculates to bethe progression of the animation at the client.

FIG. 10 is an illustration of an exemplary process flow, in accordancewith an embodiment of the present invention. FIG. 10 picks up after theimage has begun streaming to the client of the process detailed in FIG.9. Here, the client has received at least the first frame of theanimated image and the user has decided to click on one of the imagesdisplayed. Upon clicking the image (or touch in the case of a touchbased system such as an iPhone), a request is sent to a URL associatedwith the animated image. The request is processed by the link handlercomponent of the system. The link handler checks the request for anassociated image_id which is the same or deducable from the image_id inthe url of the image is being clicked on, the User Agent of the client(optional), a client_id (as noted above, the client_id could be, forinstance, a cookie, a parameter within the url of the link, IP orhostname). If no client_id exists, the link handler provides a defaultredirect URL for the click event and sends the redirect URL to theclient. This default URL may be the URL associated with the first(visible) frame of the animated image.

If the requests contains an identifiable client_id and image_id, thenthe link handler attempts to retrieve a timer associated with thecombination of both the client_id and image_id. If no timer exists, thelink handler provides a single redirect URL for the click event andsends the redirect URL to the client. Other methods familiar to thoseskilled in the art may be used as a lookup key for the timer such asusing only the client_id.

If the link handler is able to retrieve the timer associated with theclient_id, the link handler determines an appropriate redirect URL basedon the timer and the animated image associated with the timer. Using thetimer and information regarding the animated images, as well aspotentially using metadata included in the request, the link handler isable to determine which frame or image of the animated image wasdisplayed to the user during the initiation of the click (or touch)event. This allows for the content of the redirect URL to be associatedwith the actual frames or images viewed by the user during theinitiation of the click event. Once the system has determined theappropriate redirect URL, the system transmits the redirect URL to theclient.

FIG. 11 is a diagram detailing 3 exemplary embodiments of an identifiercapable of tying a client to timer data, in accordance with anembodiment of the present invention. In embodiment (a), pseudo code isshown whereby the user's e-mail address is used as the client_id. Inembodiment (b), client-server communications are shown with respect toutilization of a cookie, or metadata contained in the cookie, as theclient_id. Here a process is used to detect if a client supports cookiesor 3rd party cookies. The initial request to fetch the image isresponded with a redirect url back to the client that includes agenerated cookie. The client then attempts to fetch the redirect url (inthis case on the same server). If the cookie is present in the secondrequest, the client is deemed to support cookies and a generated ID canbe placed within the cookie and used as the client id. If the cookie ismissing, the client is deemed to not support cookies or 3rd partycookies (depending on domain setup) in this transaction. In embodiment(c), the client's IP or hostname is utilized as the client_id. Whilethese three embodiments are descriptive of preferred embodiments fordetermining a client_id, one of ordinary skill in the art wouldappreciate that there are numerous methods for assigning and determininga client_id, and embodiments of the present invention are contemplatedfor use with any method for assigning and/or determining a client_id.

The animated gif creation process may involve stitching togethermultiple static images using existing techniques such as using commandline tools such as ImageMagick or gifsicle. An advantageous step in thecreation of the final animated gif to be used by the image server,either by stitching a set of static images or an existing animated gifis to append the first frame of the animation to the end of theanimation—especially in cases where the number of loops is finite. Thereasoning for this is that this allows the timer data to “expire” and ifthe link handler receives a request from a client at a time when thetimer cannot be found or has expired (ie. the user sat on the page for avery long time and then decides to click on the image), that the linkhandler can select the URL associated with the first frame and returnthe link to the client. If the first frame is not appended to the end ofthe animation, the link handler would have to retain the timer data foran indefinite period to detect that the user clicked on the last frameafter the animated gif has stopped running.

Throughout this disclosure and elsewhere, block diagrams and flowchartillustrations depict methods, apparatuses (i.e., systems), and computerprogram products. Each element of the block diagrams and flowchartillustrations, as well as each respective combination of elements in theblock diagrams and flowchart illustrations, illustrates a function ofthe methods, apparatuses, and computer program products. Any and allsuch functions (“depicted functions”) can be implemented by computerprogram instructions; by special-purpose, hardware-based computersystems; by combinations of special purpose hardware and computerinstructions; by combinations of general purpose hardware and computerinstructions; and so on—any and all of which may be generally referredto herein as a “circuit,” “module,” or “system.”

While the foregoing drawings and description set forth functionalaspects of the disclosed systems, no particular arrangement of softwarefor implementing these functional aspects should be inferred from thesedescriptions unless explicitly stated or otherwise clear from thecontext.

Each element in flowchart illustrations may depict a step, or group ofsteps, of a computer-implemented method. Further, each step may containone or more sub-steps. For the purpose of illustration, these steps (aswell as any and all other steps identified and described above) arepresented in order. It will be understood that an embodiment can containan alternate order of the steps adapted to a particular application of atechnique disclosed herein. All such variations and modifications areintended to fall within the scope of this disclosure. The depiction anddescription of steps in any particular order is not intended to excludeembodiments having the steps in a different order, unless required by aparticular application, explicitly stated, or otherwise clear from thecontext.

Traditionally, a computer program consists of a finite sequence ofcomputational instructions or program instructions. It will beappreciated that a programmable apparatus (i.e., computing device) canreceive such a computer program and, by processing the computationalinstructions thereof, produce a further technical effect.

A programmable apparatus includes one or more microprocessors,microcontrollers, embedded microcontrollers, programmable digital signalprocessors, programmable devices, programmable gate arrays, programmablearray logic, memory devices, application specific integrated circuits,or the like, which can be suitably employed or configured to processcomputer program instructions, execute computer logic, store computerdata, and so on. Throughout this disclosure and elsewhere a computer caninclude any and all suitable combinations of at least one generalpurpose computer, special-purpose computer, programmable data processingapparatus, processor, processor architecture, and so on.

It will be understood that a computer can include a computer-readablestorage medium and that this medium may be internal or external,removable and replaceable, or fixed. It will also be understood that acomputer can include a Basic Input/Output System (BIOS), firmware, anoperating system, a database, or the like that can include, interfacewith, or support the software and hardware described herein.

Embodiments of the system as described herein are not limited toapplications involving conventional computer programs or programmableapparatuses that run them. It is contemplated, for example, thatembodiments of the invention as claimed herein could include an opticalcomputer, quantum computer, analog computer, or the like.

Regardless of the type of computer program or computer involved, acomputer program can be loaded onto a computer to produce a particularmachine that can perform any and all of the depicted functions. Thisparticular machine provides a means for carrying out any and all of thedepicted functions.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

Computer program instructions can be stored in a computer-readablememory capable of directing a computer or other programmable dataprocessing apparatus to function in a particular manner. Theinstructions stored in the computer-readable memory constitute anarticle of manufacture including computer-readable instructions forimplementing any and all of the depicted functions.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

The elements depicted in flowchart illustrations and block diagramsthroughout the figures imply logical boundaries between the elements.However, according to software or hardware engineering practices, thedepicted elements and the functions thereof may be implemented as partsof a monolithic software structure, as standalone software modules, oras modules that employ external routines, code, services, and so forth,or any combination of these. All such implementations are within thescope of the present disclosure.

In view of the foregoing, it will now be appreciated that elements ofthe block diagrams and flowchart illustrations support combinations ofmeans for performing the specified functions, combinations of steps forperforming the specified functions, program instruction means forperforming the specified functions, and so on.

It will be appreciated that computer program instructions may includecomputer executable code. A variety of languages for expressing computerprogram instructions are possible, including without limitation C, C++,Java, JavaScript, assembly language, Lisp, and so on. Such languages mayinclude assembly languages, hardware description languages, databaseprogramming languages, functional programming languages, imperativeprogramming languages, and so on. In some embodiments, computer programinstructions can be stored, compiled, or interpreted to run on acomputer, a programmable data processing apparatus, a heterogeneouscombination of processors or processor architectures, and so on.

In some embodiments, a computer enables execution of computer programinstructions including multiple programs or threads. The multipleprograms or threads may be processed more or less simultaneously toenhance utilization of the processor and to facilitate substantiallysimultaneous functions. By way of implementation, any and all methods,program codes, program instructions, and the like described herein maybe implemented in one or more thread. The thread can spawn otherthreads, which can themselves have assigned priorities associated withthem. In some embodiments, a computer can process these threads based onpriority or any other order based on instructions provided in theprogram code.

Unless explicitly stated or otherwise clear from the context, the verbs“execute” and “process” are used interchangeably to indicate execute,process, interpret, compile, assemble, link, load, any and allcombinations of the foregoing, or the like. Therefore, embodiments thatexecute or process computer program instructions, computer-executablecode, or the like can suitably act upon the instructions or code in anyand all of the ways just described.

The functions and operations presented herein are not inherently relatedto any particular computer or other apparatus. Various general-purposesystems may also be used with programs in accordance with the teachingsherein, or it may prove convenient to construct more specializedapparatus to perform the required method steps. The required structurefor a variety of these systems will be apparent to those of skill in theart, along with equivalent variations. In addition, embodiments of theinvention are not described with reference to any particular programminglanguage. It is appreciated that a variety of programming languages maybe used to implement the present teachings as described herein, and anyreferences to specific languages are provided for disclosure ofenablement and best mode of embodiments of the invention. Embodiments ofthe invention are well suited to a wide variety of computer networksystems over numerous topologies. Within this field, the configurationand management of large networks include storage devices and computersthat are communicatively coupled to dissimilar computers and storagedevices over a network, such as the Internet.

The functions, systems and methods herein described could be utilizedand presented in a multitude of languages. Individual systems may bepresented in one or more languages and the language may be changed withease at any point in the process or methods described above. One ofordinary skill in the art would appreciate that there are numerouslanguages the system could be provided in, and embodiments of thepresent invention are contemplated for use with any language.

While multiple embodiments are disclosed, still other embodiments of thepresent invention will become apparent to those skilled in the art fromthis detailed description. The invention is capable of myriadmodifications in various obvious aspects, all without departing from thespirit and scope of the present invention. Accordingly, the drawings anddescriptions are to be regarded as illustrative in nature and notrestrictive.

1. A method for simulating rendering and behavior of content across amulti-client platform, said method comprising the steps of: receivinghypertext markup language (HTML) content at a computing device; loadingHTML content in a target client and a web browser on said computingdevice; comparing, via said computing device, differences in renderingand structure between HTML content loaded in said target client and saidweb browser; and storing modification parameters for the target client.2. The method of claim 1, further comprising the steps of: modifyingsaid HTML content according to said modification parameters; entering arendering mode; applying client specific environment in a simulatedenvironment; generating simulated markup output based on said simulatedenvironment and said modification parameters; and displaying saidsimulated markup output on a display element.
 3. The method of claim 1,further comprising the steps of: generating modified markup output basedon said modification parameters; and displaying said modified markupoutput on a display element.
 4. The method of claim 3, wherein modifiedmarkup output comprises adding a client stylesheet to said HTML contentsuch that the HTML content mimics characteristics of the web browser. 5.The method of claim 3, wherein modified markup output comprisesexecuting JavaScript to attach event listeners to the elements of theHTML content such that the HTML content mimics characteristics of theweb browser.
 6. The method of claim 3, wherein modified markup outputcomprises modifying the behavior of the browser that is rendering thecontent itself such that the HTML content mimics characteristics of theweb browser.
 7. The method of claim 1, wherein the step of comparingdifferences in rendering and structure between HTML content loaded insaid target client and said web browser, comprises the steps of: parsinga Domain Object Model (DOM) Tree to determine elements that may havebeen removed or added; obtaining computed style of each DOM elementwithin the HTML content; comparing each of the DOM elements to thecomputed style in an original document; and parsing external, internaland inline styles for changes to the computed styles compared to theoriginal document.
 8. The method of claim 1, further comprising: parsinga Domain Object Model (DOM) Tree to determine elements that may havebeen removed or added; obtaining computed style of each DOM elementwithin the HTML content; comparing each of the DOM elements to thecomputed style in an original document; and parsing and comparing theHTML content.
 9. The method of claim 1, wherein the step of comparingdifferences in rendering and structure between HTML content loaded insaid target client and said web browser, comprises the steps of: parsinga Domain Object Model (DOM) Tree to determine elements that may havebeen removed or added; obtaining computed style of each DOM elementwithin the HTML content; comparing each of the DOM elements to thecomputed style in an original document; parsing external, internal andinline styles for changes to the computed styles compared to theoriginal document; and parsing and comparing the HTML content.
 10. Acomputerized system for simulating rendering and behavior of contentacross a multi-client platform, said system comprising: an applicationmodule comprising computer-executable code stored in non-volatilememory; a means for communicating data across one or more digitalnetworks, and a processor, wherein said application module, said meansfor communicating data across one or more digital networks and saidprocessor are operably connected and configured to collectively: receivehypertext markup language (HTML) content; load HTML content in a targetclient and a web browser; compare differences in rendering and structurebetween HTML content loaded in said target client and said web browser;and store modification parameters for the target client.
 11. The systemof claim 10, wherein said application module, said means forcommunicating data across one or more digital networks and saidprocessor are further configured to collectively: modify said HTMLcontent according to said modification parameters; enter a renderingmode; apply client specific environment in a simulated environment;generate simulated markup output based on said simulated environment andsaid modification parameters; and display said simulated markup outputon a display element.
 12. The system of claim 10, wherein saidapplication module, said means for communicating data across one or moredigital networks and said processor are further configured tocollectively: generate modified markup output based on said modificationparameters; and display said modified markup output on a displayelement.
 13. The system of claim 12, wherein modified markup outputcomprises adding a client stylesheet to said HTML content such that theHTML content mimics characteristics of the web browser.
 14. The systemof claim 12, wherein modified markup output comprises executingJavaScript to attach event listeners to the elements of the HTML contentsuch that the HTML content mimics characteristics of the web browser.15. The system of claim 12, wherein modified markup output comprisesmodifying the behavior of the browser that is rendering the contentitself such that the HTML content mimics characteristics of the webbrowser.
 16. The system of claim 10, wherein said application module,said means for communicating data across one or more digital networksand said processor are further configured to collectively: parse aDomain Object Model (DOM) Tree to determine elements that may have beenremoved or added; obtain computed style of each DOM element within theHTML content; compare each of the DOM elements to the computed style inan original document; and parse external, internal and inline styles forchanges to the computed styles compared to the original document. 17.The system of claim 10, wherein said application module, said means forcommunicating data across one or more digital networks and saidprocessor are further configured to collectively: parse a Domain ObjectModel (DOM) Tree to determine elements that may have been removed oradded; obtain computed style of each DOM element within the HTMLcontent; compare each of the DOM elements to the computed style in anoriginal document; and parse and comparing the HTML content.
 18. Thesystem of claim 10, wherein said application module, said means forcommunicating data across one or more digital networks and saidprocessor are further configured to collectively: parse a Domain ObjectModel (DOM) Tree to determine elements that may have been removed oradded; obtain computed style of each DOM element within the HTMLcontent; compare each of the DOM elements to the computed style in anoriginal document; parse external, internal and inline styles forchanges to the computed styles compared to the original document; andparse and comparing the HTML content.